home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 748 < prev    next >
Text File  |  1994-08-27  |  3KB  |  77 lines
  1. Subject: Re: Gem List (fwd) 
  2. Date: Tue, 12 Jul 1994 09:28:04 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. Goemon:
  7.  
  8. >>If you use a 1-pixel rectangle, then EVERY mouse movement goes back to 
  9. >>your program, and your program has to do an objc_find, EVERY TIME.
  10. >
  11. >We're not using "1 pixel rectangles" like you seem to enjoy saying alot :-)
  12. >You can get the current mouse pointer coordinates by any method you like --
  13. >as you will see in the example code, that part was specifically left "open".
  14.  
  15. 1-pixel rectangles is the most efficient method.  Of course, your code
  16. would probably have a 0ms timer event!  Horror of horrors!  [do you use
  17. MTOS?]
  18.  
  19.  
  20. >>In a single-tasking environment, it doesn't matter which you do, but in a 
  21. >>multitasking environment, the OS having to go back to your program for 
  22. >>EVERY mouse movement creates a tremendous amount of overhead that is very 
  23. >>wasteful.  Compare running your code for every 1 mouse movement to 
  24. >>running your code for every 20 mouse movements.
  25. >
  26. >You have to understand how GEM works before you can bring up an argument
  27. >like this.
  28.  
  29. I *do* understand how GEM works.  Stop these sarcastic comments NOW.
  30.  
  31.  
  32. >There is another problem here -- our library allows you to set multiple
  33. >timer events and 'attach' them to windows. If we set our event_timer to
  34. >wait for rectangle events, then the timers would become effectively
  35. >useless. The library does need to do events on a regular basis, but only
  36. >mouse events will be done if the application is TOPPED.
  37.  
  38. GEM doesn't work that way.  You wait for multiple events, and if a timer
  39. event expires first, then you process that, then continue waiting for
  40. rectangle events, and whatever other events (such as more timer events).
  41.  
  42.  
  43. >Warwick, are you SURE you understand what Extended Object Types are?  From
  44. >the way you speak, it sounds like you have no idea why they were designed.
  45.  
  46. More sarcasm.  Ignored.
  47.  
  48.  
  49. >You're saying that with Gem++ you would have to add code to support the
  50. >active slider, perhaps doing something like "register_active_slider(TREE,
  51. >object, orientation);" which is insane. Having to write code to support
  52. >an interface when the interface should do those things ITSELF is a pain.
  53.  
  54. You have to attach the slider to some other components, eg. make them
  55. control something, so you have to do some form of registration anyway. 
  56. (In GEM++, it is constructing objects).  
  57.  
  58. >If you want to make a quick change to your interface, with Gem++ you would
  59. >have to recompile the code. With all other libraries it's just a quick dip
  60. >into a resource editor to make that change.
  61.  
  62. You don't seriously believe this.  Only the most mundane of UI changes can
  63. be done without recompilation.
  64.  
  65.  
  66. >Is it any wonder why nobody has used Gem++ for anything yet? :-)
  67.  
  68. The reason is that Atari programmers are forced into using C rather than
  69. C++ by the fact that the only C++ compiler available runs way too slowly,
  70. and uses huge amounts of RAM.  We're forced to sit back in the dark ages
  71. writing GUI libraries and standards rather than writing applications with
  72. refined, consistent, object-oriented GUI libraries.
  73.  
  74.  
  75. --
  76. Warwick
  77.